fix(i18n): make a chosen language follow the reader off the static pages - #197
Merged
Conversation
Reported: pick a language on the homepage, go anywhere else, and it is English again. Reproduced exactly -- /ja/ is Japanese, and the moment you click "保存したドキュメント" you are on /history in English. The site is seven directories of static pages plus one app (/editor and /history) that lives under none of them. So there were two separate failures, and both had to go: 1. Links into the app did not carry the language. The generated homepage linked to a bare /history; history-recent.js built bare /editor?saved=... links; /history itself sent people back to "/" and opened documents without a locale. All of them now carry it, through two small helpers exported from the shell's i18n (localeHomePath, withLocale) so the app and the generator agree on where a language's homepage is. 2. The choice was never remembered. lang-switch.js only navigated: the language existed as the path the reader happened to be standing on and nowhere else. It now writes a `locale` cookie before navigating, which is the second entry in the app's resolution chain (?locale=, cookie, localStorage, browser). Both are needed. The parameter makes the first click right -- a fresh browser, a shared link, someone who never touched the switch. The cookie makes everything after it right, including typing /editor directly. Walked the whole path in a browser reporting en-US: English homepage -> pick 日本語 -> saved documents -> bare /editor -> bare /history -> a satellite page. Six steps, all lang="ja". Reverse-checked: remove the cookie and steps four and five fall back to English. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
chaxus
enabled auto-merge (rebase)
August 23, 2026 05:12
Deploying document with
|
| Latest commit: |
31f31ae
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://5de25c58.document-7hm.pages.dev |
| Branch Preview URL: | https://language-follows-reader.document-7hm.pages.dev |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reported: pick a language on the homepage, go anywhere else, and it is English again.
Reproduced exactly —
/ja/is Japanese, and the moment you click 「保存したドキュメント」 you are on/historyin English.Why
The site is seven directories of static pages plus one app (
/editorand/history) that lives under none of them. Two separate failures, both of which had to go:1. Links into the app did not carry the language. The generated homepage linked to a bare
/history;history-recent.jsbuilt bare/editor?saved=…links;/historyitself sent people back to"/"and opened documents without a locale. All of them now carry it, through two helpers exported from the shell's i18n (localeHomePath,withLocale) so the app and the generator agree on where a language's homepage is.2. The choice was never remembered.
lang-switch.jsonly navigated — the language existed as the path the reader happened to be standing on and nowhere else. It now writes alocalecookie before navigating, which is the second entry in the app's resolution chain (?locale=→ cookie → localStorage → browser).Both are needed. The parameter makes the first click right — a fresh browser, a shared link, someone who never touched the switch. The cookie makes everything after it right, including typing
/editordirectly.Verified
Walked the whole path in a browser reporting
en-US:<html lang>enjaja/editor?new=docxja/historyjajaReverse-checked: remove the cookie write and steps four and five fall back to English.
Two new cases pin it — a unit test asserting every generated page carries the locale on links into the app, and an e2e case that drives the menu and then visits the bare app URLs.
🤖 Generated with Claude Code